identifies support for Groovy/code extensions. You can extend N4 by injecting Groovy-language code that extends or becomes part of the N4 business flow. This allows for extensive customization, including but not limited to:
Updating the N4 domain model
Adding customized logic and validations
Calling existing business logic
Writing on-demand web services
Triggering new events
Integrating messages with external third-party systems
The features related to N4 code extensibility fall into these categories:
Code extensions (on page 1) are inherited in the application layer from the underlying framework layer. Code extensions are available in N4 version 2.0 and later. All code extension APIs are available in the Extension Type Registry view (on page 1). Navis recommends that you use code extensions for any future development where applicable.
Code extensions offer a more standardized approach than Groovy plug-ins, which makes them easier to use and upgrade because they are less prone to failure and require less cleanup after an upgrade.
Groovy plug-ins (on page 1) do not use the framework layer and are executed through Groovy hooks, Groovy events, Groovy code injections, or Groovy jobs. Navis plans to deprecate Groovy plug-ins, but until there are enough code extension types and triggers to replicate what you can currently do with Groovy plug-ins, Navis will not remove them. Because of this, you will want to use a code extension rather than a Groovy plug-in wherever available.
All Groovy plug-in APIs are listed in the Navis N4: SDK.
That said, as of N4 version 4.0.13, you still need to use Groovy plug-ins for the following:
General Notices
Gate business tasks
Groovy hooks for TBD Units, N4 Mobile screens, and so on
N4 supports code extensions that are subclasses from system-seeded code extensions which are delivered from Navis. You can create a code extension using Groovy code with subclasses from a Groovy class in a system-seeded code extension.
N4 does not support subclasses from non-system seeded code extensions. Code extensions, which are written as a Groovy class, cannot be overridden by a subclass. For example, if Groovy class ‘A’ is installed as a code extension, it is not possible for another Groovy class to be written as a code extension which extends or overrides ‘A’. If you create a code extension using Groovy code that are subclasses from one of your own code extensions (not system-seeded), then this code extension may not work.
The following figure gives an overview of integration transport, where identifies support for Groovy/code extensions.
In general, to be able to write good Groovy code, you should have knowledge in all areas illustrated in the following figure. Remember: Groovy is not configuration; it is programming.
The following list refers to real-life use cases; they show that you can extend N4 code to implement:
Custom validation in N4 Mobile applications
Custom gate validations for EDO and ERO
Custom validations for TBD units
Application of site-specific late arrival cutoff times
Custom gate logic for updating gross weight
Integration with external systems
Completely automated billing through scheduled Groovy jobs for invoice generation
Booking and container availability to customers (using code injection)
Custom gate calls to a third-party weigh bridge executable, including receiving results from the client's secondary database
Custom calls at the outgate stage to create the next truck visit for ring bookings if a booking is unfulfilled
Automatic creation of ERO, depending on IDO return location
Custom print reports for recording client-specific container weight records
Custom gate web service call to a third-party chassis pool validation
Custom clean truck validation based off engine year and number of visits
In This Section